The computer has greatly affected essentially all forms of information management, including the graphical editing and computer aided design and drafting (CAD) tools. Some simpler geometric modeling computer program products are two dimensional, providing only length and width dimensions of objects, while more complex and powerful computer program products provide three dimensional editing and visualization.
Three dimensional geometric modeling programs can generate a scene or part which can comprise one or more constituent 3D solid shapes. For example, a scene featuring a simple table would comprise a solid shape for each leg of the table, as well as a solid shape for a flat table top. The geometric modeling computer program typically has an executable object used to define and generate each solid shape. The object for each solid shape can have several components, the components being a combination of executable code and data structure. For example, a boundary representation (“B-rep”) component includes a data structure describing the geometry and topology data for the solid shape (e.g., length, width, depth, and coordinates of the solid part).
Most three dimensional geometric modeling programs employ a feature-based parametric modeling technique. In feature-based parametric modeling, the executable object for each solid shape has not only a boundary representation component, but also a history or creation component, referred to herein as a “feature tree” or “dependency tree,” which includes a data structure reflecting how a solid shape has been created. That is, the dependency tree includes data which indicates an order or chronological sequence of steps employed to construct the solid shape. For a simple solid block, for example, the history may indicate that the solid block began as a simple two dimensional rectangle that was extruded into a third dimension. U.S. Pat. No. 5,894,310, incorporated herein by reference, discloses solid shapes having various other components in addition to boundary representation and historical components: a visual component; a physical component; a functional component; and a behavioral component. Similarly, U.S. Pat. No. 6,392,645, incorporated herein by reference, describes a method of converting between a feature-based data structure and a direct-face data structure in graphical modeling.
Typically, when the user wants to modify a feature-based solid shape by changing any aspect of the solid shape, the feature-based parametric modeling technique re-evaluates the entire solid shape, e.g., goes through the entire CGS dependency tree in order to revise the part in accordance with the change. For example, if the user wanted to lengthen the table top of the table described above, another solid shape would be added adjacent to the previous table top. In so adding another solid shape corresponding to the increased length of the table top, another step is added to the CSG history. Alternatively, the user may modify the 2D profile of the table top and let the program to re-evaluate the solid shape of the table.
Often, a modification attempted by a user in a feature-based parametric modeling may provide a result different than that expected by the user, since existing solutions do not provide complete graphical feedback while edits are being made in the context of a dependency tree. Instead, most edits require a “roll back” of the tree to the state wherein the geometry was originally created. As the edit is performed, you cannot see the geometry that came “after” the operation currently under edit. Upon completing the edit, the tree rolls forward, taking into account the changes you have made. In the context of the “table-top” example, while the user is re-sizing the table top, the rest of the table remains static until the operation is complete, and then the remainder of the table graphic is updated.
In existing solutions, in some isolated cases, such as editing dimensional values, the edit can be made while seeing the portions of the model that are “downstream” of the current edit (i.e. in a non-rolled-back-state). However, the computations of downstream features to reflect their change as a result of the edit is delayed during this edit. It is only when the user completes the edit that he can see the results of the edit, in the form of a static update to the rest of the model.
In all cases, the existing solutions prohibit a productive and dynamic feedback loop between the user and the system. Since the user must wait to see the results of his edit, he may make incorrect decisions, lacking full information. Additionally, many types of edits, such as adjusting the shape of a surface require strong visual feedback to make the correct edit. While rubber-banding may be provided in isolated instances, such as updating a surface while the curve is being edited, no known system updates the entire tree, or significant portions of it, during the edit. So, for example, if the user wants to evaluate how his edit to a curve affects the rounds that depend on the surface generated by the curve, he cannot see this interactively in current solutions.
There is, therefore, a need in the art for an improved system and method for dynamic propagation and display of graphical edits in history-based modeling systems.